Amazon Connect 公式ブートキャンプをやってみよう！ – STEP 4「既存問い合わせ対応の実装」

みなさん、こんにちは！
福岡オフィスの青柳です。

AWSから公開されている「Amazon Connect Bootcamp」を題材に「ステップ・バイ・ステップ」で構築方法を解説する連載記事の第5回目です。

• STEP 0：「準備編」
• STEP 1：「メニューを備えた基本的な問い合わせフロー」
• STEP 2：「発信者番号による顧客情報の照会と本人確認」
• STEP 3：「新規問い合わせ時のコールバックの実装」
• STEP 4：「既存問い合わせ対応の実装」 ← 当記事です
• STEP 5：「メニューをDTMFからAmazon Lexへ変更」

今回は、顧客が「過去に問い合わせを行った件について再び電話で問い合わせた」というシチュエーションで、顧客のエクスペリエンスを向上するテクニックを紹介します。

具体的には、顧客情報DBから取得した情報を利用して、以下のことが行えるようにします。

• 対応履歴や調査ステータスを確認することができる (機械音声による自動読み上げ)
• 前回対応したエージェントを指名して電話に繋いでもらうことができる

今回の構築範囲

今回は、図で「赤線」で囲まれているフロー、すなわち

• Flow 7：「既存問い合わせ」
• Flow 8：「前回対応したオペレーターへ繋ぐ」

の処理を作り込んでいきます。

フローの構築

Flow 7「既存問い合わせ」

このフローでは「対応履歴や調査ステータスを確認することができる (機械音声による自動読み上げ)」の処理を実装します。

フローの全体図はこのようになります。

図の(5)、(6)に相当するブロックは、前回までのステップにて作成済みです。

今回は(1)～(4)および(7)のブロックを追加します。

(1) 「ブランチ」-「コンタクト属性を確認する」

「ユーザー定義」の属性「message」の値を確認します。

• 確認する属性：
  • タイプ： 「ユーザー定義」を選択
  • 属性： 「message」を選択
• チェックする属性：
  • 「別の条件の追加」をクリック
  • 「等しい」「Success」を選択

「STEP 2：発信者番号による顧客情報の照会と本人確認」にも出てきましたが、このブロックでは「顧客の電話番号をキーに顧客情報が正常に取得できたか否か」を判定しています。

もし顧客情報の取得に失敗している場合は、この後に続く「顧客情報DBから取得した情報を使って対応履歴・調査ステータスを読み上げる」処理が行えませんので、(2)～(4)をスキップして(5)まで進み、次のフローへ遷移します。

(2) 「操作」-「顧客の入力を取得する」

項目が多いため、前半と後半に分けます。

• プロンプト： 「テキスト読み上げまたはチャットテキスト」→「テキストの入力」の順に選択
• テキスト： (下記に記載の通り入力)
• 解釈する： 「SSML」を選択

「テキスト」の内容は以下の通り入力してください。

<speak>
$.Attributes.lName 様。
前回のお問い合わせ番号は <say-as interpret-as="digits"> $.Attributes.caseNumber </say-as> です。
<break time="1s"/>
このお問い合わせ番号についてメッセージを聞きたい場合は1を、
オペレーターとお話ししたい場合は2を、
押してください。
</speak>

前回のステップまでは、プロンプトの設定項目「解釈する」は全て「テキスト」を選択していました。
今回初めて「SSML」を選択しています。

「SSML」とは「Speech Synthesis Markup Language」(音声合成マークアップ言語) のことであり、音声合成アプリケーションに言葉を喋らせる際に「タグ」を使って様々な指示を与えるために使われます。

例えば、電話番号やID番号などの「数字の羅列」を読み上げさせたい場合、単に「12345678」というテキストを指定すると「せんにひゃくさんじゅうよんまんごせんろっぴゃくななじゅうはち」と読み上げられてしまいます。 そのような場合に「この文字列は数字を一桁ずつ読み上げる」と指示をすることにより、「いち・に・さん・し・ご・ろく・なな・はち」と読み上げさせることができます。

このブロックでは、2種類のSSMLタグが使われています。

• <say-as interpret-as="digits"> ～ </say-as>： さきほど説明した「数字を一桁ずつ読み上げる」指示です
• <break time="1s"/>： 読み上げ途中に指定した秒数の「間」(ま) を入れます

Amazon Connectで使用可能なSSMLのリファレンスは、AWSドキュメントの下記ページを参照してください。
Amazon Connectでサポートされている SSML タグ

(※ なお「SSML」はAWS独自のものではなく、W3Cが制定した標準仕様です)

続けて、キー入力受付の設定を行います。

• 入力方法： 「DTMF」タブを選択
• タイムアウトの設定： 「5秒」と入力 (適宜調整してください)
• オプション： 「別の条件を追加」をクリックして、以下の値を入力 (2回繰り返す)
  • 「1」
  • 「2」

「1」(この問い合わせ番号についてメッセージを聞きたい) が選択された場合は、(3)へ進みます。

「2」(オペレーターと話したい) が選択された場合は、(3)(4)をスキップして(5)まで進み、次のフローへ遷移します。

(3) 「操作」-「プロンプトの再生」

• プロンプト： 「テキスト読み上げまたはチャットテキスト」→「テキストの入力」の順に選択
• テキスト： (下記に記載の通り入力)
• 解釈する： 「SSML」を選択

「テキスト」の内容は以下の通り入力してください。

<speak>
お問い合わせ番号 <say-as interpret-as="digits">$.Attributes.caseNumber</say-as> についてのメッセージは次の通りです。
<break time="1s"/>
$.Attributes.caseNotes
</speak>

さきほどと同様に「SSML」を使った記法になっています。

ユーザー定義属性を示す「$.Attributes.caseNotes」には文字列値「ステータス。優先度を上げて対応中。コメント。お問い合わせ内容は現在調査中です、午後3時に状況を更新します。」が格納されており、そのまま読み上げられます。

(4) 「操作」-「顧客の入力を取得する」

項目が多いため、前半と後半に分けます。

• プロンプト： 「テキスト読み上げまたはチャットテキスト」→「テキストの入力」の順に選択
• テキスト： 「オペレーターとお話しするには1を押してください。」と入力
• 解釈する： 「テキスト」を選択

• 入力方法： 「DTMF」タブを選択
• タイムアウトの設定： 「5秒」と入力 (適宜調整してください)
• オプション： 「別の条件を追加」をクリックして、以下の値を入力
  • 「1」

「1」(この問い合わせ番号についてメッセージを聞きたい) が選択された場合は、(3)へ進みます。

「1」以外のキーが押されたり、タイムアウトになった場合は、(6)へ進んで通話が終了します。 (顧客が「対応状況が聞けたのでオペレーターと話す必要はない」と判断したというパターンでしょうね)

Flow 8「前回対応したオペレーターへ繋ぐ」

このフローでは「前回対応したエージェントを指名して電話に繋いでもらうことができる」の処理を実装します。

フローの全体図はこのようになります。

図の(8)、(9)に相当するブロックは、前回までのステップにて作成済みです。

今回は(1)～(7)および(10)のブロックを追加します。

(1) 「ブランチ」-「コンタクト属性を確認する」

• 確認する属性：
  • タイプ： 「ユーザー定義」を選択
  • 属性： 「message」を選択
• チェックする属性：
  • 「別の条件の追加」をクリック
  • 「等しい」「Success」を選択

「Flow 7」と同じく「顧客の電話番号をキーに顧客情報が正常に取得できたか否か」の判定です。

顧客情報の取得に成功している場合は(2)へ進んで「前回対応したエージェントへ繋ぐ」処理を行います。

しかし、顧客情報の取得に失敗している場合は(6)へ進み、通常のキューに入ることにより「空いているオペレーター」が対応することになります。 (顧客情報が参照できないので「前回対応したエージェント」が分からないためです)

(2) 「ブランチ」-「人員の確認」

「人員の確認」ブロックは、対応可能なエージェントが存在するかどうかをチェックするためのものです。

• チェックするステータス： 「利用可能」を選択
• 確認するキュー： チェックを入れる
• 確認対象： 「エージェント別」→「属性を使用する」の順に選択
• タイプ： 「ユーザー定義」を選択
• 属性： 「lastAgent」と入力

チェックは「キュー単位」「エージェント単位」のいずれかで行うことができます。

• キュー単位： キューを担当するエージェントのうち対応可能な者が一人でも存在するのか、全員対応不可能なのか
• エージェント単位： 特定のエージェントが現在対応可能なのか、別の電話を対応中あるいは離席中のため対応不可能なのか

ここでは「エージェント単位」の対応可否をチェックしています。

チェック対象のエージェントはユーザー定義属性「lastAgent」の値で指定します。 この「lastAgent」には、顧客情報DBから取得した「前回対応したエージェントのユーザーログイン名」が格納されています。

判定の結果「前回対応したエージェントが現在対応可能な状態」であれば、(3)へ進みます。

「前回対応したエージェントは現在対応不可能な状態」であれば、(6)へ進み「空いているオペレーター」へ回されます。

(3) 「操作」-「顧客の入力を取得する」

項目が多いため、前半と後半に分けます。

• プロンプト： 「テキスト読み上げまたはチャットテキスト」→「テキストの入力」の順に選択
• テキスト： 「前回 $.Attributes.lName 様のお問い合わせに対応したオペレーターは $.Attributes.lastAgent です。このオペレーターと再度お話しをしたい場合は1を押してください。」と入力
• 解釈する： 「テキスト」を選択

• 入力方法： 「DTMF」タブを選択
• タイムアウトの設定： 「5秒」と入力 (適宜調整してください)
• オプション： 「別の条件を追加」をクリックして、以下の値を入力
  • 「1」

「前回対応したエージェント」の名前を案内した上で、このエージェントに繋ぐかどうかを確認しています。

「1」が選択された場合、(4)へ進んで「前回対応したエージェント」へ繋ぐ処理を行います。

(4) 「設定」-「作業キューの設定」

• 出力： 「エージェント別」→「属性を使用する」の順に選択
• タイプ： 「ユーザー定義」を選択
• 属性： 「lastAgent」と入力

ここまでのステップでは「作業キューの設定」では「キュー」を指定していました。

しかし、ここでは「キューに割り当てられたエージェントのうちの誰か」に繋がってはダメで、特定のエージェントに繋ぐ必要があります。

したがって「エージェント別」を選択して、ユーザー定義属性「lastAgent」でエージェントを指定しています。

(5) 「操作」-「プロンプトの再生」

• プロンプト： 「テキスト読み上げまたはチャットテキスト」→「テキストの入力」の順に選択
• テキスト： 「オペレーター $.Attributes.lastAgent へお繋ぎしています。」と入力
• 解釈する： 「テキスト」を選択

前回対応したエージェントへ繋ぐ準備ができたため、エージェントに繋ぐ直前に最後のアナウンスを流します。

(6) 「設定」-「作業キューの設定」

(6)～(7)のルートでは、「前回対応したエージェント」ではなく「空いているエージェント」が対応することになります。

• 出力： 「キュー別」→「キューの選択」の順に選択
• キュー： 「InquiryQueue」を選択

「新規問い合わせ」のキューを指定しています。

(7) 「操作」-「プロンプトの再生」

• プロンプト： 「テキスト読み上げまたはチャットテキスト」→「テキストの入力」の順に選択
• テキスト： 「オペレーターへお繋ぎしています。」と入力
• 解釈する： 「テキスト」を選択

特定のエージェントへ繋ぐ訳ではないため、単に「オペレーターへ繋ぎます」とアナウンスします。

(8) 「終了/転送」-「キューへ転送」

こちらのブロックは前回までのステップで作成済みですので、設定内容は割愛します。

このフローでは、途中で以下の2通りのルートに分かれます。

• (4)～(5)のルート (前回対応したエージェントへ繋ぐ)
• (6)～(7)のルート (空いているエージェントへ繋ぐ)

いずれのルートを通った場合も、このブロック(8)に到達します。

しかし、(4)～(5)のルートではキューの指定が「(前回対応した) エージェント」、(6)～(7)のルートではキューの指定が「新規問い合わせキュー」にそれぞれ設定されているため、同じ「キューへ転送」ブロックであっても挙動が異なるという訳です。

実際に電話を掛けて動作をテストする

さて、これで「STEP 4：既存問い合わせ対応の実装」の全ての設定が終わりました。

例によって、実際に電話を掛けてみて動作を確認しましょう。

テストシナリオ：既存問い合わせメニューから「対応履歴・調査ステータス」のメッセージを聞き、前回対応したエージェントと会話する

今回の動作テストでは、顧客情報DBに格納された「前回対応したエージェント」の情報が「saburo」に設定されています。 したがって、エージェント「saburo」でログイン・CCP起動の状態にしておきます。

電話を掛けて本人確認を行うまでの手順は割愛します。 (今回のシナリオでは顧客情報DBに登録されている電話番号から掛けて「本人確認」を行う必要があります)

• 「購入前のご相談は1を、新規のお問い合わせは2を、以前のお問い合わせについては3を押してください」のアナウンスが流れる
• プッシュボタンで「3」を押す
• 「彩木様。前回のお問い合わせ番号は1234です。このお問い合わせ番号についてメッセージを聞きたい場合は1を、オペレーターとお話ししたい場合は2を押してください」のアナウンスが流れる
• プッシュボタンで「1」を押す
• 「お問い合わせ番号1234についてのメッセージは次の通りです。ステータス：優先度を上げて対応中。コメント：お問い合わせ内容は現在調査中です、午後3時に状況を更新します」のアナウンスが流れる
• 「オペレーターとお話しするには1を押してください」のアナウンスが流れる
• プッシュボタンで「1」を押す

ここでエージェント「saburo」が対応可能な状態 (ログイン済みで、状態がAvailableであり、通話中ではないこと) であれば、以下のように続きます。

• 「前回彩木様のお問い合わせに対応したオペレーターはsaburoです。このオペレーターと再度お話しをしたい場合は1を押してください」のアナウンスが流れる
• 「オペレーターsaburoへお繋ぎしています」のアナウンスが流れる
• エージェント「saburo」のCCP画面に顧客からの着信が通知される

いかがでしょうか、期待した通りの動作を確認できましたでしょうか？

余裕があれば「saburo」「shiro」の各エージェントでそれぞれCCPを起動した状態にしておき、

• 「前回対応したエージェント」に繋がるパターン
• 前回対応したエージェントが対応不可能な場合に「空いているエージェント」に繋がるパターン

の各パターンをそれぞれ確認すると、今回のフローの動きをより深く理解できるかと思います。

おわりに

今回は「既存問い合わせ対応の実装」の構築を行いました。

ここまでのステップで、今回のブートキャンプで実装する要素のほぼ全てが組み込まれた「コールセンターシステム」が完成しました。

次は、いよいよ最後のステップ「STEP 5：メニューをDTMFからAmazon Lexへ変更」です。 是非ご覧ください。